REMARKS 

Claims 1-33 are pending in the application. Claims 1, 27, 32, and 33 are 
independent claims. Claims 1-33 stand rejected by the examiner. Claim 34 has been 
added. Assignee traverses the instant claim rejections. 

Interview Summary 

Assignee's representative would like to thank examiner Cam Y. T. Truong for the 
courtesies extended to assignee's representatives, David Bultman, Fonda Daniels-Farrar, 
and John Biernacki during the telephone interview on July 20, 2006. The interview 
discussed claim l's limitation that the first data in the first data page is configured to 
store a second key that is a duplicate of the first key and that corresponds to second data 
stored on a second data page. Figure 1 1 of Hara was discussed in the context of such 
limitations of claim 1 . Claims 25 and 26 were also discussed. The remarks and the 
amendments contained herein further summarize the interview. 

Claim Rejections - 35 USC §101 
Claims 1-26 stand rejected under 35 USC § 101 because the language of the claim 
raises a question as to whether the claim is directed merely to an abstract idea. Assignee 
respectfully disagrees but to expedite prosecution of the application, assignee has 
amended claims 1-26 to recite a computer-implemented information processing system 
involving a database system and that the first, second and third keys of claim 1 are used 
for searching a set of data records. In view of the foregoing, assignee submits that the 
instant rejection has been traversed and that the claims should proceed to issuance. 
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Claim Rejections - 35 USC §§102 and 103 

Claims 1, 3, 5-9, and 11-26 stand rejected under 35 USC § 102 as being 
anticipated by Hara (U.S. Patent No. 6,571,250). Claims 2 and 4 stand rejected under 35 
USC § 103 as being unpatentable over Hara in view of Li (U.S. Patent No. 6,647,381). 
Claims 10, 27-33 stand rejected under 35 USC § 103 as being unpatentable over Hara in 
view of Ishak (U.S. Patent No. 5,475,837). Assignee traverses the instant rejections. 

Claim 1 is directed to a computer-implemented information processing system 
involving a database system with a plurality of data records accessible through a B tree 
structure, wherein a set of the data records have duplicate keys. More specifically, claim 
1 recites that first data in a first data page is configured to store a second key which is a 
duplicate of a first key and which corresponds to second data stored on a second data 
page. The second data is configured to store a third key that is a duplicate of the first key 
and that corresponds to third data. The first key points to the second key, and the second 
key points to the third key. The first, second and third keys are used for searching the set 
of the data records. 

As a non-limiting example of claim 1, figure 8 of assignee's specification 
provides an illustration where a B-tree has duplicate keys on data pages. In this example, 
the key "42" (shown at 400) has five unique values, in other words the key "42" is 
duplicated multiple times (as shown at 401, 402, 403, 404, 405). Key "42" points to the 
data and first duplicate key 401 that are located on a data page. The first duplicate key 
401 points to the next duplicate key 402 that is on a different data page, and so on. 

The cited reference Hara does not disclose the limitations of claim 1, such as 
claim l's limitations that second data is configured to store a third key that is a duplicate 
of the first key and that corresponds to third data, and that the first key points to the 
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second key, and the second key points to the third key. Hara lacks any details regarding 



such limitations of claim 1 . 

For example figure 1 1 of Hara does not disclose such limitations of claim 1 . 

Figure 1 1 is used in Hara to describe "the configuration of a conventional B-tree having 

many duplicate key data" (see Hara at column 3, lines 66-67) and the problems of such a 

conventional B-tree. Figure 1 1 is described as follows at column 2, lines 36-62 in Hara: 

As shown in FIG. 11, there are the following problems with the B- 
tree index having a number of same keys. In the B-tree index 
shown in FIG. 11, table data information relating a key is managed 
by one leaf entry 16. The leaf entry 16 includes a key 14, table data 
information 18 (data record identifier) relating to the key value, 
and a number 17 (number of duplication) of pieces of table data 
information 18 relating to the key value. The table data 
information 18 is arranged in an ascending order in a list form of 
duplication. In this storage system, when the number of duplication 
of a key increases, the length of a leaf entry cannot be stored in a 
leaf node 12. As a result, the table data information for one key has 
to be divided into a plurality of leaf entries, and stored in a 
plurality of nodes. In the example shown in FIG. 1 1, the entries of 
the keys '28' are stored separately in three nodes, that is, leaf 
nodes N4, N5, and N6. In this structure, the entries of the keys '28 A 
are bottlenecks in scanning leaf nodes using a pointer in the 
horizontal direction corresponding to the range search. 
Furthermore, the key 14 contained in an upper node 13 stored in 
the root node 10 and the upper node 13 has also to be a key in the 
table data information in addition to *28\ thereby causing the 
problem that the number of a root node 10 and the upper node 13 
increases. As a result, a duplicate key lowers not only the 
performance of the access process on a duplication key itself, but 
also the access performance of the entire B-tree index, and the 
storage efficiency. 

This passage from Hara is only illustrating a conventional B-tree index and 
problems associated with a conventional B-tree index. As shown by this passage, Hara 
does not disclose the limitations of claim 1, such as claim l's first key pointing to a 
second key which points to a third key, wherein the second key and the third key are 
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duplicates of the first key. Because Hara does not disclose the limitations of claim 1, 
Hara cannot anticipate claim 1 . Accordingly claim 1 is allowable and should proceed to 
issuance. Because claim 1 is allowable, the dependent claims of claim 1 are also 
allowable over Hara. 

With respect to newly added dependent claim 34, claim 34 recites that the third 
key of claim 1 points to the second key, and that the second key points to the first key. 
This allows the links between the keys to be bi-directional so as to allow find-backward 
operations as well as a find-forward operations. Hara does not disclose the limitations of 
claim 34. Accordingly claim 34 is allowable for this additional reason and should 
proceed to issuance. 

Independent claims 27, 32, and 33 recite that first data in a first data page is 
configured to store a second key which is a duplicate of a first key and which corresponds 
to second data stored on a second data page. The second data is configured to store a third 
key that is a duplicate of the first key and that corresponds to third data. The first key 
points to the second key, and the second key points to the third key. As discussed above, 
Hara (whether viewed alone or in combination with the other cited references) does not 
disclose such limitations of these claims. Accordingly claims 27, 32, and 33 are 
allowable and should proceed to issuance. 

[Continued on next page] 
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CONCLUSION 




For the foregoing reasons, assignee respectfully submits that claims 1-33 are 
allowable. Therefore, the examiner is respectfully requested to pass this case to issue. 
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